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SYSTEM AND METHOD FOR PRIVATE AND SECURE 
FINANCIAL TRANSACTIONS 

Inventors: Len L. Mizrah 

BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates to a system and method for private and secure transactions 
and more particularly to a system and method for providing private and secure buy/sell or 
withdraw/deposit transaction environment within financial institutions and at merchants / sellers 
/ vendors transaction-processing systems. 

Description of the Related Art 

Basic financial transactions including buy/sell and withdraw/deposit, have always 
required security to protect the financial account holder, the financial institution where the 
account resides, and a merchant/seller/vendor or other party at the point of sale from identity 
theft and fraudulent transactions. Due to wide spread use of computer networks and electronic 
commerce as a new medium to perform transactions, new requirements to maintain validity and 
integrity of financial transactions are arising. There are companies gathering, sorting, 
researching and selling for profit consumers' private personal information acquired during 
financial transactions. It would be advantageous to provide an efficient system and method to 
protect customers' privacy during financial transactions. Another new requirement is associated 
with the fact that hackers and intruders getting an illegal access to the computer network can 
compromise financial transactions. This aspect of transactions' security is addressed in U.S. Pat. 
No. 6,092,202 to Veil et al. 

Throughout the entire history of financial transactions, privacy and security were 
addressed by the best contemporary technologies. Since the onset of the computer network era, 
computer power, relational databases, software environments and communication lines have 
been used by financial institutions for security and privacy functions. Banks, then credit card 
companies and eventually brokerage companies and other financial institutions have used them 
to perform authentication, authorization and accounting, referred to as AAA, at their back 
offices during financial transactions. 

- 1 - 
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Financial transactions with credit cards suffer significant losses due to weaknesses in 
implementing the authentication stage of financial transaction. A party at the point of sale 
compares human signatures visually on a card (if there is any) and on a selling slip. This 
operation is error prone when identifying faked signatures in a case of fraudulent actions. If a 
financial account holder loses an unsigned credit card it is easy to fake signatures as one can 
place any signature on a card before requesting a financial transaction. Another typical 
malfunction at the authentication stage of financial transaction occurs when someone gets a 
credit card account number and a copy of the card owner's signature. This enables fraud even 
with non-stolen credit cards. Another example where financial institutions incur losses is caused 
by financial account holders, when they change their minds after concluding a financial 
transaction. A financial account holder can repudiate the financial transaction by claiming that 
somebody transacted in their place. 

These examples show that there is a real and substantial need for an improved financial 
transaction architecture at the authentication stage of financial transaction. The fact that mistakes 
in authenticating non-real credit card owners followed by successful authorization and 
accounting sessions at financial institution back offices illustrate another weakness of the 
financial transaction architecture. Authorization and accounting stages are de-coupled from the 
actual financial account holder, while the authentication stages are de-coupled from financial 
institution back office computers. 

Though credit cards have been used as a financial transaction instruments since the 
beginning of electronic commerce, there is number of issues in architecture that have become 
apparent. For instance, credit card data, a social security number, a card holder name, phone, 
address etc., while transferred through the Internet, are not absolutely secure and can fall into 
"wrong hands" due to communication channel leaks. It is obvious that while high speed data 
flow through the Internet or other communication channels is a big advantage for financial 
transactions, insufficient data security makes it highly desirable to alter the financial transaction 
architecture to avoid potential data leaks on communication lines (Internet and non-Internet as 
well). 

Another issue jeopardizing financial transactions in electronic commerce is weakness of 
the authorization stage of financial transactions with credit cards. Neither the authorization stage 
nor the accounting stage are actively controlled and timed by financial account holders. 
Numbers of non-requested sell transactions may happen before a financial account holder 
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regains control on his/her account. U.S. Pat. No. 5,485,510 to Colbert and U.S. Pat. No. 
6,052,675 to Checchio disclosed attempts to improve the authorization stage of financial 
transactions in order to enhance financial transaction security. The Colbert patent proposed to 
alter financial transactions by authorizing a financial account holder before he/she applies to a 
5 merchant (a vendor). Information supplied to financial institution back office includes a credit 
card account number, a secret PIN and merchant / financial transaction specific information (at 
least, merchant ID number and financial transaction amount). Then the merchant is given only 
the authorization code, while the card number and the PIN remain unknown to the merchant or 
anybody, if the card is lost or stolen. Similar architecture is offered in the Checchio patent, 
10 except a merchant does not get any authorization code, but rather a credit card account number. 
Since the financial transaction is pre-authorized in this case, a merchant sends into the financial 
institution back office a credit card account number and merchant / financial transaction specific 
information, which is compared with data given by the financial account holder during the pre- 
authorization stage. Neither a merchant nor anybody can use the card without knowing a secret 

15 PIN, if it is lost or stolen. 

Though both patents allow improve security against fraudulent usage of credit cards for 
certain types of transactions, there are limitations to be addressed. Both patents are centered on 
phone lines, when communicating to financial institution back offices. Frequent usage of a pair 
of static numbers over phone lines is insecure due to leaks at the line entries and on the lines 

20 themselves. This issue gets aggravated, if one would like to replace phone lines by wireless or 
the Internet communication lines. Another weakness common to both patents is lack of a system 
and / or method as to how the financial institution back office is supposed to handle proposed 
architectural changes for mass financial transactions. Financial transaction architectures ought to 
cover financial account holders, financial institutions and a party at the point of sale in a 

25 mutually dependent way. A necessity to have prior to the authorization stage knowledge of a 
party at the point of sale and other financial transaction specifics is an additional limitation in 
both proposed innovations. That narrows down types of possible financial transactions and 
locations, in which they can be performed from. 

There is a public concern that financial transactions with credit cards either in electronic 

30 commerce channels or in other traditional channels could lead to private personal consumers' 
information being accessed, monitored, tracked, stolen and fraudulently used or sold for profit 
often without the consumers' approval. Privacy related problems are exacerbated with the 
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advanced Internet related technologies due to the ease with which information can be collected, 
processed and combined with other information. 

It is not only financial transactions with credit cards which raise numerous privacy 
issues. Even during standard withdraw/deposit financial transactions at a bank, a financial 
5 account holder would not always like a bank teller to have access to his/her private personal 
information file. It would be beneficial if a financial account holder could decide whether this 
privilege should be given to the bank teller. More often than not, withdraw/deposit financial 
transactions at a bank require financial account holder identification documents to be revealed, 
which can be viewed as a certain privacy related inconvenience justified by the current state of 

10 the authentication architecture during financial transaction. 

FIG. 1 A illustrates a block diagram of a conventional system for performing withdraw / 
deposit transactions. In order to perform financial transactions, a legal adult 101 (or a legal 
business) is supposed to have an account with a financial institution. It is standard to disclose a 
private, personal information profile 102 to the financial institution during the account 

15 application process. At step 104, the financial institution, which permitted an account opening, 
creates a personal log file in the financial institution back office establishes a withdraw / deposit 
mechanism, and issues personal checks and cards. Then financial account holder, whether it is a 
legal person 101 or a legal business, can perform deposit 105 or withdraw 106 transactions. 
Typical deposit transactions to a bank or a brokerage house 107 are made through either a direct 

20 / mailed deposit with a personalized deposit slip 1 09 or by submitting a check on one's name 
and disclosing one's account number. Another way of obtaining deposits is used by insurance 
117 and credit card companies 115, which receive paid statements 119 from financial account 
holder. Checks 110, debit cards 1 12 or Graphical User Interfaces (GUI) over the Internet 1 13 are 
used by financial account holders for withdraw transactions with a bank or a brokerage house 

25 108. The credit card 1 16 is a typical withdraw mechanism for withdraw transactions with credit 
card companies (whether they are banks like Visa and Master Card or not, like American 
Express). Another withdraw mechanism is used by financial account holders when dealing with 
insurance companies 1 18. A request for payment 120 is to be made in accordance with the 
insurance policy. 

30 There are deficiencies in the deposit / withdraw transaction system described above 

related to privacy and security of the financial account holder and financial institution 
performing transactions including the following: 
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1) Direct and urgent deposit transactions can be hindered, if the financial account holder 
is located far away from the bank and its branches where the account resides. It should be 
possible to deposit to one's account via other financial institutions, without disclosing private 
personal information of financial account holders at other financial institution's intermediate 

5 service levels. 

2) During depositing, bank tellers get access to the private personal information of the 
financial account holder. There are two issues here. Firstly, a teller can make mistakes altering 
personal and account balance information without any immediate financial institution back 
office CPU and dB control. In other words, each deposit transaction has a probability of 

10 mistakes, hurting the bank and the financial account holder. Secondly, the financial account 
holder may not like a bank teller to have access to his / her private personal information file 
during direct depositing. At this stage it would be beneficial, if financial account holder could 
decide him- / her-self whether this privilege should be given to the bank teller. 

3) Insufficient theft and fraud protection during withdraw transactions with checks, 
15 credit, charge and debit cards or during electronic commerce financial transactions. 

4) Private personal information is not protected and often intentionally or 
unintentionally misused by a party at the point of sale or bank tellers during withdraw 
transactions. 

FIG. IB illustrates a block diagram of a conventional system for performing buy / sell 
20 transactions. Once financial account holder 121, has made a buying decision 122 and applied to 
a party at the point of sale, the actual selling transaction is enabled through cash 124, credit 
cards 116, debit cards 112, checks 1 10 or electronic commerce 125. Though cash is handy for 
low value financial transactions, it is usually impractical for the bulk of mass financial 
transactions due to low cash amount on hand. All other financial transaction instruments except 
25 cash, such as credit cards 1 16, debit cards 112, electronic commerce 125 and checks 110 lead to 
either complete or partial disclosure of private personal information 127, and are therefore prone 
to private personal information misuse and fraudulent actions 128. 

FIG. 2 illustrates a block diagram of a conventional system and method for performing 
authentication, authorization and accounting sessions during buy / sell transactions with a credit 
30 card, a charge card or a debit card. As illustrated in FIG. IB and FIG. 2, once a financial account 
holder 121 has made a buying decision 122 and applied to a party at the point of sale, a point-of- 
sale (POS) device scans static information on a credit card and sends an authorization request to 
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financial institution back office, specifying price (money transaction amount), to perform a 
withdraw transaction 205. The financial institution back office CPU checks whether there is 
enough money in the database under this account and if yes, and if the card is not marked in the 
database as lost, stolen or fraudulently used, authorizes the withdraw transaction 206 (it sends an 
5 authorization code to POS device). Steps 205 and 206 constitute the authorization stage 201 of 
the financial transaction. It is worthwhile to note that in the conventional financial transaction 
system with credit / debit cards, the authorization stage is performed prior to authentication and 
accounting stages of the financial transaction. 

Once the transaction authorization is sent to a party at the point of sale 206, the first 

10 accounting step 202 is performed. The account under transaction is left with a locked sum of 
money to assure a payment to a party at the point of sale 207. The payment is made after 
deduction of the transaction fee to the card issuing bank and the discount rate fee to the 
acquiring bank or an independent sales organization, which provided the merchant status to a 
party at the point of sale. Once step 207 is completed, the financial institution back office is 

15 ready for another transaction of the same financial account holder, provided the requested 
spending limit is not exceeded. 

Then if the credit card is signed, the signatures on the selling draft and on the card are 
visually compared at a party at the point of sale for off line financial transactions 208. If the card 
is not signed, identification documents are requested from financial account holder 209. Steps 

20 208 and 209 are components of the authentication stage of financial transaction 203 for the 
conventional offline financial transaction system. It can be noted here that the conventional 
electronic commerce on line financial transaction system based on credit / debit card usage 
skips step 208, and instead enforces step 209, requiring quite wider disclosure, than in a case of 
offline financial transaction, of financial account holder private personal information. Then the 

25 final step of accounting stage 204 is performed. Step 210 includes the following: a party at the 
point of sale sends the selling draft inside the selling batch after trade hours to the acquiring 
bank (or an independent sales organization). The acquiring bank re-routes the respective part of 
the batch to the card issuing bank to unlock the payment and transfer it to a merchant account 
after deductions, specified in the merchant's agreement. Then the money is placed into a 

30 merchant account in few days. 

The conventional financial transaction architecture based on credit / debit cards and 
shown in FIG. 2 has the following weaknesses, which the present invention addresses: 
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1) Authentication stage is de-coupled from financial institution back office CPU and dB, 
making it subjective, embarrassing, error and fraud prone. 

2) Authorization stage is de-coupled from financial account holder for both on and off 
line financial transactions, making it especially dangerous for on line financial transactions (due 

5 to on line financial transaction latency, a number of unauthorized financial transactions may 
happen before financial account holder regains control on the account). 

3) Private personal information leaks are possible on the Internet communication lines 
during electronic commerce sessions (browsing technology, TCP/IP protocols, PKI, SSL and 
other Internet technologies do not guarantee sufficient financial transaction security). 

10 4) Accounting stage is de-coupled from financial account holder, keeping one at 

inconvenience during a series of buy / sell financial transactions. 

5) A party at the point of sale may collect and analyze financial account holder private 

personal information, and market and sell it for profit. This leaves public at large unaware of 

privacy and confidentiality status of the data. 
15 Present on line and offline financial transaction architectures have substantial security 

and privacy deficiencies at the authentication, authorization and accounting stages. It would be 

highly desirable to provide an improved system and method wherein consumers can perform 

financial transactions with financial institutions without privacy and security concerns. The 

present invention addresses these problems. 
20 SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to cut off merchants / sellers / vendors 

from consumers' private personal information during financial transactions. 

A further object of the present invention is to allow a financial account holder to cut off 

bank tellers from their private personal files during withdraw/deposit transactions. 
25 A further object of the present invention is to provide a method, which couples together a 

financial account holder and a financial institution back office during the authentication stage of 

financial transaction to insure highly elevated and enhanced security of financial transactions. 

A further object of the present invention is to create the authentication stage architecture 

of financial transactions, which makes the authentication stage of financial transactions a 
30 transaction specific one; e.g. it can be used just only for one particular financial transaction. 
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A further object of the present invention is to include the beginning of the accounting 
session of a financial transaction into the authentication stage architecture of financial 
transaction to enhance transaction specific authentication architecture. 

A further object of the present invention is to architect a financial transaction 
5 authentication session in a way that makes a positive authentication outcome a time specific one 
for a particular financial transaction . 

A further object of the present invention is to design a system and to provide a method 
for financial transactions that enables merchants / sellers / vendors to request financial institution 
back offices to authorize and to account financial transaction just for one particular financial 
10 transaction requested by financial account holder. 

A further object of the present invention is to include the end of the accounting session 
into the authorization stage architecture of financial transaction. 

A further object of the present invention is to create financial transaction architecture 
that provide a high security level even in an environment with possible leaks on communication 
15 lines due to incomplete security of such Internet technologies as SSL (Secure Socket Layer), 
TCP/IP protocol, WEB browsers etc. 

A further object of the present invention is to provide "clocked" AAA for financial 
institution back offices that allows implementation of financial transaction specific AAA 
architectures. 

20 The present invention is a system and method for providing private and secure financial 

transactions. The system and method comprise a "clocked" AAA method embedded into 
financial institution back office privacy layer architectures. The architecture comprises "back 
office connection devices" for use by financial account holders to connect to financial institution 
back offices. Such devices include for example regular phones, and personal computers with a 

25 specific Graphical User Interface (GUI) invoked through a Universal Resource Locator (URL) 
address. Alternatives include network computers or wireless personal organizers, interactive TV 
set sessions or smart cards with customized read / write devices to interact with financial 
institution back offices. The architecture comprises also a financial institution back office central 
processing unit ("the CPU"), which could include a farm (or cluster) of compute and file servers 

30 operated under either UNIX Sun/Solaris or Windows NT operating system; a number of 

software programs (software modules) designed to implement various functions of "clocked" 
AAA; a relational database (dB) inside financial institution back offices, where the actual 
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account information is stored and accessed. The financial institution back office includes a dB 
connected to the CPU where information is processed using the "clocked" AAA program 
environment. 

The present invention allows consumers having membership with any financial 
5 institution to perform financial transactions in a highly secure and private manner. Financial 
account holder private personal information need not be disclosed to a party at the point of sale 
nor a bank teller. Finally, the system and method are well adapted to the current and upcoming 
software, hardware and electronic commerce technologies and can be easily implemented given 
an acceptable business trade off. 

10 A method for managing financial transactions according to the present invention includes 

performing an authentication process, an authorization process and an accounting process. The 
authentication process is executed for a predicted transaction by a particular account holder. The 
predicted transaction has a predicted transaction amount and a predicted transaction time. The 
authentication process produces a transaction signature for presentation upon execution of the 

15 predicted transaction. The authorization process for a particular transaction has an actual 

transaction amount and an actual transaction time which are determined upon presentation of the 
transaction signature. The authorization process includes verifying that the presented transaction 
signature matches the transaction signature for the predicted transaction, that the actual 
transaction amount matches the predicted transaction amount, and that the actual transaction 

20 time matches the predicted transaction time. The accounting process for the particular 

transaction is performed as a result of a successful authorization process. The accounting 
process includes reconciling the predicted transaction amount and actual transaction amount for 
the particular account holder. 

According to one embodiment of the invention, the predicted transaction amount and the 

25 transaction signature for a predicted transaction are stored in an authentication record in a 

database at the financial institution back office. Likewise, an authorization record is created 
during the authorization process. The authorization record and the authentication record are 
compared to complete the authorization process for the transaction. Thus, the authentication 
record includes the predicted transaction amount and the transaction signature. Also, a predicted 

30 transaction time is stored in the database which holds the authentication record, as for example, 
a time out interval length used in combination with a time of creation of the authentication 
record, or for another example, as an absolute time value. 
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One representative embodiment of the authentication process includes establishing a 
communication session between the particular account holder and the financial transaction 
server, accepting an account number as input, prompting the particular account holder to supply 
a static identification number at a first instance, and a dynamically identified combination of 
5 digits from personal identification code, where in the combination is not include all the personal 
identification code, at a second instance. Further, the predicted transaction amount is accepted 
as input. The transaction signature is produced and sent to the particular account holder. The 
information identifying the predicted transaction, and the time stamp are stored in an 
authentication record. 

10 A representative embodiment of the authorization process includes establishing a 

communication session between a party to the particular transaction and a financial transaction 
server. At the server, a presented transaction signature is accepted and an actual transaction 
amount is received as inputs. The server compares the time of the particular transaction with the 
predicted time, and the presented transaction signature and the actual transaction amount with 

15 the predicted transaction amount and the transaction signature associated with the transaction. 
An authorization message is sent to the party to the transaction upon successful matching of the 
parameters. 

The process for managing financial transactions according to present invention works 
with or without identification of the financial account holder during the authorization process. 

20 In various embodiments, the present invention comprises a system which executes the 

authentication process, the authorization process, and the accounting process utilizing 
communication media interconnecting the financial institution back office with individual end 
stations, such as cell phones, point-of-sale devices, personal computers, handheld computers, 
and the like. In an alternative embodiment, the present invention comprises an article of 

25 manufacture storing computer programs used for executing the processes as outlined above. 

In yet other embodiment, the present invention provides a financial transaction server 
including communication resources, processing resources, and data storage resources utilized for 
managing the processes described above. 

The present invention also provides a method for automated authentication, authorization 

30 and accounting for financial transactions. The method comprises establishing an authentication 
record for a predicted transaction by a particular account holder. The authentication record 
includes information identifying a predicted transaction having a predicted transaction amount 
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and a transaction time parameter. Also, an authenticated transaction signature for presentation 
upon execution of the predicted transaction is included in the authentication record. The method 
also comprises establishing authorization record for a particular transaction indicating an actual 
transaction amount, an actual transaction time and a presented transaction signature. The 
5 authorization record and the authentication record are matched to determine whether the 

presented transaction signature matches the authenticated transaction signature for the predicted 
transaction, whether the actual transaction amount matches the predicted transaction amount, 
and whether the actual transaction time matches the transaction time parameter. Finally, the 
predicted transaction amount and actual transaction amount are reconciled for the particular 
10 account holder. According to various embodiments, the method includes storing the 

authentication record in a database including a plurality of authentication records for predicted 
transactions. The process involves periodically attempting to match authentication records with 
authorization records being created with a timed algorithm, which automatically times out 
authentication records based on their time of creation and a parameter determining a length of 
1 5 time within which the predicted transaction must be completed. 

In sum, a secure and private financial transaction process is provided that can be 
deployed efficiently and which addresses many of the deficiencies of other existing systems. 

Other aspects and advantages of the present invention can be seen on review of the 
drawings, the detailed description and the claims which follow. 
20 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 A is a block diagram of a conventional system for performing withdraw/deposit 
transactions. 

FIG. IB is a block diagram of a conventional system for performing buy/sell 
transactions. 

25 FIG. 2 is a block diagram of a conventional system and method for performing 

authentication, authorization and accounting sessions during buy/sell transactions with a credit 
card or a debit card. 

FIG. 3 is a flow diagram of the embedded privacy and security layer EPSL architecture 
for either buy/sell or withdraw/deposit transactions. 
30 FIG. 4 is a flow diagram of the EPSL authentication session (while on financial account 

holder side). 
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FIG. 5 is a flow diagram of the EPSL authentication session (while on financial 
institution back office CPU and dB side). 

FIG. 6 is an interface protocol of the EPSL architecture. 
FIG. 7 is a flow diagram of the EPSL authorization session. 
5 FIG. 8 is the EPSL transaction checklist. 

FIGS. 9 A, 9B and 9C are a synthesis of a timing diagram, a flow chart and a functional 
diagram of the EPSL architecture based on the "clocked" AAA technology. 

DESCRIPTION OF PREFERRED EMBODIMENTS 
FIG. 3 shows a flow diagram of an embedded privacy and security layer EPSL 
10 architecture for buy / sell and withdraw / deposit transactions according to the present invention. 
Financial account holder 121 makes a transaction decision 122 irrespective whether it is going to 
be on or offline financial transaction and independent of the point of sale (or a bank teller) 
locations. It is assumed at this stage that the financial account holder knows an approximate or 
exact amount of money, which will be required to perform the predicted financial transaction. 
15 Following the transaction decision (step 122), at step 301, the financial account holder initiates 
an authentication session with a financial institution back office CPU and dB where financial 
account holder account resides. Details of how the authentication session is performed at 
financial institution back office according to present invention is described later. However, 
several features of step 301 are disclosed here. 
20 The financial account holder has to go through three tiers of financial institution back 

office security protection, to initiate the authentication session. First two tiers are based on 
disclosing a financial institution EPSL account number and then a transaction (deposit or 
withdraw) static PIN secret number, which are intended to be known only to financial account 
holder and financial institution back office. Since the financial institution back office may be 
25 accessed by a financial account holder through various dedicated communication lines, which 
have non-guaranteed security protection, a third security protection tier is included. The third 
tier is based on an interactive dialog between the financial institution back office and the 
financial account holder. The back office prompts the account holder to enter a random subset 
of digits particular to the given communication session of an identity PIN secret number, which 
30 is known only to financial account holder and financial institution back office. The third security 
protection tier allows eliminating any potential information leaks at the entry devices and on the 
communication lines themselves. Whoever intercepts the random digit combination, requested 
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during the third tier processing from financial account holder, will not be able either reuse it or 
reengineer the entire identity PIN. 

Another feature of step 301 is that the financial institution back office prompts the 
financial account holder to enter the predicted transaction amount of money. Then, at the end of 
5 the authentication session 302, an alphanumeric transaction signature is generated at the 
financial institution back office 303 and transferred back to financial account holder. This 
signature is specific to a particular financial transaction amount requested by financial account 
holder, and has a limited life time, set by default to a reasonable time interval sufficient enough 
to perform the financial transaction. It should also be noted here that the alphanumeric signature 

10 can be used for only one financial transaction and can not be reused. 

Once the financial account holder is authenticated for a particular financial transaction , 
there is still room to back off from the financial transaction. To execute the transaction, the 
financial account holder submits the alphanumeric transaction signature to a party at the point of 
sale (merchant or a bank teller) along with a financial institution EPSL account number. Neither 

15 the alphanumeric signature nor the financial institution EPSL account number contains any 
private personal information, which could be associated with the financial account holder 
requesting a party at the point of sale to continue a financial transaction . At step 305 a party at 
the point of sale initiates an authorization session with financial institution back office CPU and 
dB. In addition to the alphanumeric transaction signature and financial institution EPSL account 

20 number given by the financial account holder, the party at the point of sale adds a business ID 
and an actual transaction amount of money and then sends this time stamped information 
sequence for authorization at financial institution back office. The detailed system and method to 
perform an authorization session at financial institution back office will be discussed later. 
Information sent by the party at the point of sale (or a bank teller) for authorization is sufficient 

25 enough not only for an authorization session decision making process 306, but for accounting 
session completion as well 307. At this moment, the financial transaction is completed in a 
highly secure manner without disclosing financial account holder private personal information to 
a party at the point of sale. 

The top level financial transaction architecture disclosed above is applicable to on and 

30 offline financial transactions. Though hardware and software environments at the point of sale 
locations (like POS devices, GUI, selection of communication lines etc.) may vary for each of 
those two cases, the fundamental architecture of private and secure financial transactions 
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remains the same. The authentication stage, becomes the first performed step in the system and 
has paramount priority and security enforcement. It is not a party at the point of sale any more, 
who authenticates the financial account holder, but the financial institution back office. It 
prevents fraud, embarrassment and private personal information misuse by a party at the point of 
5 sale (or a bank teller). The financial account holder can not repudiate the financial transaction, 
as nobody else could transact it in his or her place. The authorization and accounting stages of 
the financial transaction in the revealed system architecture can not occur without a prior request 
by the financial account holder. Thus, authorization and accounting are coupled with the actual 
financial account holder, while authentication sessions became tightly coupled with the financial 

1 0 institution back office. 

FIG. 4 illustrates a flow diagram of the EPSL authentication session (from the financial 
account holder side). Basically, it is a more detailed flow diagram of steps 121 - 122 - 301 - 302 
- 303 shown earlier in FIG.3, which all together constitute the authentication session for the 
financial account holder with the financial institution back office. The financial account holder 

15 is expected to use various devices and communication lines to be able to reach financial 

institution back office. As illustrated in FIG. 4, example communication devices include point of 
sale POS devices 401, conventional phone lines and mobile phones 402, network computers 
with URL / GUI capabilities 404 and desktop personal computers connected to the Internet (or 
specialized financial institution on line services) 405. Once connection to the financial 

20 institution back office is established, the financial account holder is first requested to enter a 
financial institution EPSL account number 406 (the first security tier). Then the financial 
account holder is requested to enter a transaction type static PIN secret number 407 (the second 
security tier) and a requested random combination of digits from an identity PIN secret number 
408 (the third security tier). Finally, the financial account holder enters an expected transaction 

25 amount of money 409. A failure in making any of steps 406 - 407 - 408 - 409 leads to refusal by 
the financial institution back office to perform the authentication session. It is expected that the 
financial account holder at this point will try again to initiate an authentication session or contact 
the financial institution EPSL representative after the second rejection 308. Successful 
completion of these steps ends up with an alphanumeric transaction specific signature generated 

30 at financial institution back office and transferred back to financial account holder 303. Step 409 
is a last step in the authentication session, and it begins the accounting session at financial 
institution back office. In this step 409, the transaction amount of money requested by financial 
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account holder is compared with an amount available in the account. The amount predicted 
should not be less than the actual amount specified later by a party at the point of sale (or a bank 
teller) during the authorization session request. It is important to note that step 303 will not be 
reached and the authentication stage at step 409 will be rejected, if the credit / debit financial 
5 institution EPSL card is listed at financial institution back office as lost, stolen or fraudulently 
used. The authentication stage at step 409 will also be rejected, if the transaction amount of 
money requested by financial account holder exceeds available ones at financial institution 
EPSL account. 

FIG. 5 shows a flow diagram of the EPSL authentication session (from the financial 

10 institution back office CPU and dB side). Due to a central position occupied by an 

authentication session in the disclosed financial transaction system architecture, it is necessary 
to show how financial institution back office system is adapted to handle the authentication 
session. A financial account holder initiates the authentication session with the financial 
institution back office 301 in the same way and through the same communication devices / 

15 channels as shown in FIG. 4. Although a detailed system and method of perfonriing AAA at 
financial institution back office will be described later, certain features specific to the 
authentication session features are discussed here. 

At decision-making step 504, ACCOUNT NUMBER SEARCH PROGRAM module 502 
is activated in the financial institution back office CPU / dB, which transitions the authentication 

20 session to next decision-making step 506, provided financial institution EPSL account number 
verification is successful. At step 506 TRANSACTION PIN VERIFICATION PROGRAM 
module 503 is activated and transitions the authentication session to decision-making step 508, 
provided transaction type PIN verification in the financial institution back office dB is 
successful. At step 508 IDENTITY PIN RANDOM SUBSET GENERATOR module 505 is 

25 activated at financial institution back office CPU and transitions the authentication session to 
decision-making step 509, provided a random subset of digits is validated at the financial 
institution back office dB. At step 509 ACCOUNT CONSISTENCY PROGRAM module 507 is 
activated at the financial institution back office CPU and transitions the authentication session to 
decision-making step 511, provided the transaction amount of money, specified by financial 

30 account holder during an authentication session does not exceed available funds in the account. 
At step 511 the authentication session is completed at the financial institution back office and 
the accounting session is begun 510, unless the financial institution EPSL card is in the list of 
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lost, stolen or fraudulently used, which would lead to rejecting the entire authentication session. 
Otherwise, the authentication file will be generated, time stamped and put on hold at financial 
institution back office dB concurrently with the alphanumeric financial transaction specific 
signature, which is generated and sent to the financial account holder. One may note that a 
5 number of program modules 502, 503, 507 and 510 are incorporated into financial institution 
back office software environment to perform an authentication session. This is just a part of the 
automated "clocked" AAA sessions, which constitute the system and method at financial 
institution back office to enable financial institution EPSL technology. 

FIG. 6 shows an interface protocol of the EPSL architecture. The columns correspond to 

10 nodes that process parameters. A parameter name in a cell shows where the parameter is 

originated. If an arrow onset begins from the cell, where a parameter is originated, an arrowhead 
shows where the parameter is delivered to for further processing. If an arrow onset cell location 
is different than the cell location in the same row at which the parameter originates, this arrow 
shows a destination cell to which a parameter was moved for processing in an earlier exchange, 

15 and from which it is moved again as indicated by the arrow. 

Parameter ACC#_{XYZ} 601 is financial institution EPSL account number. "XYZ" 
should be broadly constructed to mean a certain number, which uniquely characterizes financial 
institution EPSL financial account holder. Parameter W_PIN 602 is a withdraw transaction PIN 
secret number. Parameter D_PIN 603 is a deposit transaction PIN secret number. Parameter W$ 

20 604 is withdrawal transaction amount, specified by financial account holder during an 

authentication session. Parameter D$ 605 is a deposit transaction amount, specified by financial 
account holder during an authentication session. Parameter ID_PIN 606 is the identity PIN 
secret number, used by financial institution back office and financial account holder during an 
interactive part of an authentication session. Parameter (W/D)#_GEN(ACC#_{XYZ}, 

25 (W/D)_PIN, ID_PIN, (W/D)$, TX1) 607 is an alphanumeric signature, generated at the end of a 
successful authentication session. (W/D)#_GEN is a function of other parameters, listed above. 
The only unknown yet parameter is TX1, which is a time point at which an authentication 
session is successfully completed (see FIG. 9). Parameter T_INT((W/D)#_GEN(ACC#_{XYZ}, 
(W/D)_PIN, ID_PIN, (W/D)$, TX1)) 608 is a time interval, counted from the moment TX1 . It 

30 specifies an alphanumeric signature lifetime for a specific financial transaction derived 

internally at financial institution back office at the end of a successful authentication session. 
Parameter ACC#_{XYZ}_TX1 609 is an authentication file name, defined at the end of a 
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successful authentication session inside financial institution back office. Parameter 
ACC#_{XYZ}_TX2 610 is an authorization file name, defined at the beginning of a successful 
entry data transfer at the beginning of an authorization session inside financial institution back 
office. Parameter BUS# 61 1 is a merchant / seller / vendor standard ID number specified by a 
5 party at the point of sale during an authorization session request. Parameter T- AMOUNT 612 is 
an exact amount of money, required to perform financial transaction and specified by a party at 
the point of sale (or a bank teller) during an authorization session request. 

FIG. 7 shows a flow diagram of the EPSL authorization session. It corresponds to steps 
305 - 306 - 307 in FIG. 3. All together they constitute the authorization session of financial 

10 transaction. A party at the point of sale can access the financial institution back office to initiate 
the authorization session using the same devices / communication lines 401-405 as financial 
account holder, when initiating the authentication session (see financial institution GS. 4-5). 
Though a detailed system and method of performing AAA at financial institution back office 
will be described later, certain specific to the authorization session features can be described 

15 here. 

At decision-making step 704, ACCOUNT NUMBER SEARCH PROGRAM module 502 
is activated at financial institution back office CPU / dB and transitions the authorization session 
to decision-making step 706, provided the account number is positively verified at the financial 
institution back office dB. Otherwise, the authorization session is denied. At decision-making 

20 step 706, TRANSACTION SIGNATURE VERIFICATION PROGRAM module 703 is 

activated at the financial institution back office CPU and transitions the authorization session to 
decision-making step 708, provided the alphanumeric transaction signature is validated at the 
financial institution back office dB. At decision-making step 708, BUSINESS ID 
VERIFICATION PROGRAM module 705 is activated at the financial institution back office 

25 CPU and transitions an authorization session to decision-making step 709, provided a party at 
the point of sale ID is on a list of valid, legal merchants. At decision-making step 709, 
ACCOUNT VERIFICATION PROGRAM module 707 is activated at the financial institution 
back office CPU and transitions the authorization session to decision-making step 306, provided 
the predicted transaction amount entered by financial account holder at the respective 

30 authentication session is more than or equal to the actual amount, entered by a party at the point 
of sale, while requesting the authorization session. At decision-making step 306, the financial 
institution back office completes authorization and accounting sessions, provided the credit / 
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debit EPSL account card is not on a list of lost, stolen or fraudulently used cards. This checks 
again whether there are no suspicious issues related to this particular account since the 
authentication session was completed. 

It can be noted here that a number of program modules 502, 703, 705, 707 and 307 are 
5 incorporated into financial institution back office software environment to perform an 
authorization session. As will be seen later, this is part of the automated "clocked" AAA 
sessions, which constitute the system and method implemented at the financial institution back 
office to enable financial institution EPSL technology. 

FIG. 8 shows the EPSL transaction checklist. Pluses mean that a particular parameter in a 
10 respective row is used during one of AAA sessions, specified at the top of the columns. Minuses 
mean that parameters are not used. 

FIGS. 9A, 9B and 9C illustrate a synthesis of a timing diagram, a flow chart and a 
functional diagram of the EPSL architecture based on the "clocked" AAA technology. One may 
note that the part, related to the AUTHENTICATION SESSION (a dotted line of a non- 
15 numbered cell), is already presented in FIGS. 4-5, while the part named the AUTHORIZATION 
SESSION (also a dotted line of a non-numbered cell) is described in FIG.7. 

The financial institution back office has GLOBAL CLOCK PROGRAM module 902. A 
hardware equivalent is implemented as a silicon digital integrated circuit internal clock (with a 
typical rate approximately within the range (10 - 1,000) MHz). Module 902, which can be fed by 
20 similar clock at financial institution back office CPU, synchronizes all program modules during 
AAA sessions. Each financial transaction beginning from the start of the authentication session 
and up to the end of the authorization and accounting sessions is processed depending on then- 
time position, defined by the global clock. The global clock synchronizes all program modules. 
Every program module is activated by one of the other program modules once its job is 
25 completed. Key information elements of financial transactions stored in financial institution 
back office dB (for instance, authentication and authorization files) are strictly analyzed and 
differentiated depending on their positions in time, which is a part of a decision making process 
at financial institution back office. The global clock program module enables financial 
transaction related timing components and parameters identification as well as the entire EPSL 
30 system of program modules and hardware synchronization at financial institution back office. 
A financial account holder initiates the authentication session with the financial 
institution back office through any of described above devices / communication lines by entering 
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a series of numbers (three tiers security protection system described above). Once the beginning 
of a communication session is established, module ACCOUNT NUMBER SEARCH 
PROGRAM 502 is activated, requesting the financial account holder to enter a financial 
institution EPSL account number. Once the financial account holder has entered 
5 ACC#_{XYZ} 601, if ACC#_{XYZ} is positively verified, module 502 activates module 
TRANSACTION PIN VERIFICATION PROGRAM 503 and stops its own execution. If 
ACC#_{XYZ} is not verified at the financial institution back office dB, the financial transaction 
authentication session is denied and module 502 stops execution without activating module 503. 
Decision-making routine ACC# 504 is a part of module 502 and makes a decision whether to 
10 activate module 503 or not, based on ACC#_{XYZ} verification results at financial institution 
back office dB. 

TRANSACTION PIN VERIFICATION PROGRAM module 503, once activated, 
requests the financial account holder to enter a transaction PIN and executes, once the W_PIN 
602 or D_PIN 603 is entered. Decision-making routine T PIN 506, which is a part of module 
15 503, stops module 503 and activates IDENTITY PIN RANDOM SUBSET GENERATOR 

module 505, provided (W/D)_PIN is positively verified at the financial institution back office 
dB. Otherwise, routine T PIN 506 stops module 505 and the financial transaction authentication 
session is denied. 

Module 505 once activated, generates a request to the financial account holder to submit 
20 in sequence a certain random combination of digits that constitute a subset of a financial account 
holder identity PIN secret number ID_PIN 606 and then executes on analyzing a received reply, 
entered by financial account holder during this interactive session (the third tier of financial 
institution back office security protection). Decision-making routine ID_PIN 508, which is a part 
of module 505, stops module 505 and activates financial institution back office ACCOUNT 
25 CONSISTENCY PROGRAM module 507, provided the random subset of digits, entered by 
financial account holder per the request of module 505 is positively validated at financial 
institution back office dB. Otherwise, routine ID_PIN 508 stops module 505 execution without 
activating module 507 and the financial transaction authentication session is denied. 

A financial institution back office ACCOUNT CONSISTENCY PROGRAM module 
30 507, once activated, requests the financial account holder to enter a predicted withdraw 

transaction amount W$ 604 or predicted deposit transaction amount D$ 605 and executes, once 
(W/D)$ is entered. Decision-making routine 509, which is a part of module 507, stops module 
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507 and activates TRANSACTION SIGNATURE GENERATOR module 905, provided W$ 
does not exceed the amount of money available on this financial institution EPSL account. 
Otherwise, routine (W/D)$ 509 stops module 507 execution without activating module 905 and 
the financial transaction authentication session is denied. 
5 TRANSACTION SIGNATURE GENERATOR module 905, once activated, generates 

an alphanumeric signature, provided all previous steps 504, 506, 508 and 509 are successful. 
Decision-making routine (W/D)#_GEN 511, which is a part of module 905, stops module 905 
and activates module 904, provided the credit / debit financial institution EPSL account card is 
not on a list of lost, stolen or fraudulently used cards. Concurrently with activating module 904, 

1 0 routine 511 sends the alphanumeric transaction signature to the financial account holder 510. 

AUTHENTICATION FILE GENERATOR module 904, once activated, creates an 
electronic record, which contains some or all of the information gathered together during the 
authentication session: ACC#_{XYZ} 601, (W/D)_PIN 602 or 603, ID_PIN 606, (W/D)$ 604 or 
605 and (W/D)#_GEN 607. The record is given a file name is ACC#_{XYZ}_TX1 609, which 

15 is a combination of financial institution EPSL account number and a time mark TX1. TX1 is a 
time moment, at which file ACC#_{XYZ}_TX1 907 is generated in financial institution back 
office dB. Practically speaking, it is the same time as when the financial account holder obtains 
his alphanumeric signature for a requested financial transaction. The time mark TX1 is assigned 
at the end of the authentication session for the financial account holder and financial institution 

20 back office in this example. The authentication record with the file name ACC#_{XYZ}_TX1 
can be created irrespective to which operating system is deployed at financial institution back 
office dB (for instance, UNIX / Solaris or Windows NT). Module 904 activates module 901 at 
the time moment TX1 . 

Financial institution back office WATCHDOG PROGRAM module 901, starting from 

25 the time moment TX1, searches financial institution back office dB after each small time 

interval (which can range for example, from several milliseconds to several seconds, depending 
on actual hardware / software implementation of financial institution back office CPU and dB). 
The search checks whether there is another record with the same root name ACC#_{XYZ} and 
suffix TX2 greater than TX1 (TX2 > TX1). Module 901 can work in this mode of operation 

30 during time interval TJGNT 608, which starts at TX1 and is set at financial institution back office 
to a reasonable time to perform a predicted financial transaction after the authentication session 
(for instance, a half an hour). Otherwise, it can be chosen by the financial account holder during 

-20- 

F:\CLIENTS\AIDT\1000-l\appln.wpd 



AIDT 1000-1 



the authentication session within certain range (for example, from a quarter of an hour to several 
hours). The record with file name ACC#_{XYZ}_TX2 906, which financial institution back 
office WATCHDOG PROGRAM module 901 is searching for, is created during the 
authorization session, requested by a party at the point of sale from the financial institution back 
5 office. The authentication session completed at the moment TX1 is followed by the 

authorization session, which has an intermediate stage of creating an authorization record at 
financial institution back office at some later time moment TX2 after TX1 . The authorization 
file structure and its role in the "clocked" AAA technology will be discussed later along with the 
authorization session description. 

1 0 The financial institution back office WATCHDOG PROGRAM module 90 1 stops 

searching for an authorization file 906 at the moment TX1 + T_INT. Any authorization session, 
initiated by a party at the point of sale after that time will be denied with a message that the 
transaction signature is timed out. The financial account holder will need to initiate another 
authentication session for the same financial transaction to make it happen. Strictly speaking, 

15 module 901 will keep searching financial institution back office dB after the moment TX1 + 

T_INT with gradually increased time interval between consecutive search sessions (for instance, 
double interval for TX1 + T INT < t < TX1 + 2* T INT, triple interval for TX1 + 2 * T_INT < t 
< TX1 + 3 * T_INT, etc.). However, its function is changed. When the authorization file is 
found, module 901 will forbid financial transaction with the error message that financial 

20 transaction is timed out. At certain time moment (for instance, TX1 + 10 * T_INT) module 901 
completely stops searching for the authorization file ACC#_{XYZ}_TX2 906. Any 
authorization session initiated by a party at the point of sale for the same financial transaction 
will be simply denied from now on. 

The reason module 901 search repetition time interval is getting gradually increased after 

25 the moment TX1 + T_INT is to reduce the load on financial institution back office CPU. 

Limiting the lifetime of transaction signatures and making them specific to particular financial 
transactions allow eliminating any fraudulent actions based on decryption of these signatures. It 
greatly enhances security in using non-secure communication lines and line input / output 
devices. It is especially important for on line financial transaction and makes the EPSL 

30 technology a very suitable architecture for electronic commerce as well as for offline financial 
transactions. 
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The financial account holder applies to a party at the point of sale (or a bank teller) after 
obtaining the alphanumeric transaction signature at the end of the authentication session. A party 
at the point of sale (merchant or a bank teller) initiates an authorization session with the financial 
institution back office using the same devices / communication lines as possible during the 
5 authentication session (see financial institution GS. 4-5). A party at the point of sale gets from 
the financial account holder, a financial institution EPSL account number and a financial 
transaction alphanumeric signature. Then the party at the point of sale adds up a standard 
business identification (merchant) number BUS# 61 1 and an actual transaction amount of money 
T- AMOUNT 612 necessary to perform financial transaction. Those are added to the 
10 authorization process for accounting processing at financial institution back office during the 
accounting session. 

At decision-making step 704, ACCOUNT NUMBER SEARCH PROGRAM module 502 
is activated, once a party at the point of sale sends the ACC#_{XYZ} 601 and it is received at 
financial institution back office. Then module 502 performs two steps, provided ACC#_{XYZ} 

15 601 is a legitimate one (positively verified at the financial institution back office dB). Module 
502 activates AUTHORIZATION FILE GENERATOR module 903 at the time moment TX2, 
which actually symbolizes the beginning of the authorization session at financial institution back 
office. Module 903 creates the authorization record with file name ACC#_{XYZ}_TX2 906 in 
the financial institution back office dB, and is kept active during the time when all authorization 

20 session entry information is passing through steps 706 - 708 - 709 and eventually gathered 
together in the authorization record ACC#_{XYZ}_TX2. In the second step, module 502 
transitions the authorization session to decision-making step 706, provided again the account 
number 601 is positively verified at financial institution back office dB. Otherwise, the 
authorization session is denied through dedicated device 701 at financial institution back office, 

25 notifying a party at the point of sale with the error message of incorrect financial institution 
EPSL account number. 

WATCH DOG PROGRAM module 901 activated at the moment TX1 keeps periodically 
searching financial institution back office dB. It is looking for the authorization record, which 
complements to the authentication record ACC#_{XYZ}_TX1 and, once the authorization 

30 record ACC#_{XYZ}_TX2 is created, module 901 eventually finds it. If the authorization 
record is created during time interval TX1 < t < TX1 + T_INT, the authorization session is 
continuing. Otherwise, it is denied. WATCHDOG PROGRAM module 901 right after the 
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authorization file is found and positively identified with respect to time it is created, activates 
TRANSACTION SIGNATURE VERIFICATION PROGRAM module 703, ACCOUNTING 
SESSION VERIFICATION PROGRAM module 707 and BUSINESS ID VERIFICATION 
PROGRAM module 705. All these modules start processing information they are looking for in 
5 the authorization record or keep periodically looking at this record, until the expected 
information appears there after steps 706 - 708 - 709. 

At decision-making step (W/D)#_GEN 706 the financial transaction alphanumeric 
signature is already transferred from a party at the point of sale to the financial institution back 
office and module 703 is activated (if it is not activated yet by module 901) and compares 
10 alphanumeric signatures in the authentication record and the authorization record. In a case they 
match, module 703 transitions the authorization session to decision-making step BUS# 708. 
Otherwise, the authorization session is denied with the error message that the transaction 
signature is incorrect. 

At decision-making step BUS# 708, a party at the point of sale business ID BUS# 61 1 is 

1 5 already transferred from a party at the point of sale to the financial institution back office and 
BUSINESS ID VERIFICATION PROGRAM module 705 is activated unless it was already 
activated by module 901 . Module 705 checks whether a party at the point of sale BUS# is on the 
list of valid, legal merchants and then transitions the authorization session to decision-making 
step T-AM 709. Otherwise, the authorization session is denied with the error message that 

20 merchant ID is incorrect. 

At decision-making step T-AM 709, a party at the point of sale specified exact 
transaction amount of money T- AMOUNT 612 transferred from a party at the point of sale to 
financial institution back office, is written to the authorization record 906 and ACCOUNTING 
SESSION VERIFICATION PROGRAM module 707 is activated, unless it was already 

25 activated by module 901 . Module 707 reads out T- AMOUNT from the authorization record 906 
and checks whether it is less or equal to the withdraw or deposit amount (W/D)$ specified in the 
authentication record 907. If T- AMOUNT is less or equal (=<) (W/D)$ (T- AMOUNT =< 
(W/D)$), module 707 locks T- AMOUNT at the financial account holder financial institution 
EPSL account to assure the payment to a party at the point of sale (after deductions of the 

30 transaction fee to the card issuing bank and the discount rate to the acquiring bank or an 

independent sales organization). This completes the accounting session, which is performed next 
after the authorization session. 
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If module 502 and 703 positively identifies a financial transaction after comparing 
authorization record 906 and authentication record 907 at decision-making step T-SIGN VERIF 
908, the authorization session is transitioned to decision-making step 306. Otherwise, the 
authorization session is denied through dedicated device / channel 701 at financial institution 
5 back office. 

At decision making step ACC- VERIF 306, the accounting session gets completed and 
the financial transaction is permitted, provided module 705 and 707 positively identified BUS# 
61 1 and T-AMOUNT 612 at financial institution back office dB. Otherwise, the financial 
transaction is denied. As can be seen, a successful completion of the accounting session is an 

10 essential part of the entire authorization process. The authorization code is sent to the financial 
account holder through dedicated device / channel 909 from the financial institution back office, 
provided the accounting session is successfully completed and the credit / debit financial 
institution EPSL account card is not on a list of lost, stolen or fraudulently used cards. This 
allows checking again whether there are no suspicious issues related to this particular account 

15 since the authentication session was completed. Authentication and authorization records are 
kept in financial institution back office dB for ongoing accounting control until they are 
archived. 

Several notes about the described above "clocked" AAA technology at financial 
institution back office follow. First, how to perform chargeback using this technology is 

20 described. Chargeback is a credit card transaction that is billed back to a party at the point of 
sale, who made the sale. This occurs when financial account holder disputes a charge on their 
bill by claiming the product was never delivered or financial account holder was dissatisfied 
with it in some way. If a party at the point of sale and financial account holder agrees with the 
chargeback and its amount, the financial account holder requests financial institution back office 

25 to authenticate a deposit financial transaction using D_PIN secret number during the 

authentication session (instead of usually used W_PIN for buy / sell transactions). Then financial 
account holder submits to a party at the point of sale the alphanumeric signature along with the 
EPSL account number. In other words, chargeback is performed as a regular financial 
transaction with the only difference that the transaction signature generated at financial 

30 institution back office is for deposit financial transaction. Then a party at the point of sale 

requests financial institution back office to authorize this financial transaction in the same way 
as a withdraw financial transaction . Once the transaction is authorized at financial institution 
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back office, a request to lock the chargeback amount is sent to the acquiring bank or an 
independent sales organization, where this merchant account is residing in order to guarantee the 
payment back to financial account holder. EPSL chargeback mechanism allows performing this 
financial transaction within standard EPSL architecture (referring back to FIG. 3) without 
5 disclosing to a party at the point of sale financial account holder private personal information. 

The financial institution back office "clocked" AAA technology is adapted to service a 
party at the point of sale during authorization sessions requested by them independent of the 
entry data flow rate on particular devices and / or communication lines. In an extreme case, 
when a party at the point of sale enters ACC#_{XYZ}, (W/D)#_GEN, BUS# and T-AMOUNT 

10 manually, modules 703, 705 and 707 are activated by module 901, once module 502 verifies 

ACC#_{XYZ} and the authorization record ACC#_{XYZ}_TX2 906 is created in the financial 
institution back office dB. This file can be empty for a while, until the following parameters are 
entered. Until then each of the mentioned modules 703, 705 and 707 periodically looks at the 
authorization file, and picks up the parameter of interest as soon as it arrives at financial 

15 institution back office and is written into the authorization file. Alternatively, in the case that a 
party at the point of sale uses a specialized point-of-sale POS devices, which allow for high 
speed electronic data entry for the listed above parameters, modules 703, 705 and 707 will find 
needed parameters in the authorization file ACC#_{XYZ}_TX2 at the very first moment they 
were activated. In this case, modules 703, 705 and 707 could be activated by decision-making 

20 routines 706, 708 and 709 sooner than by module 901 . That depends on specifics of hardware 
and software implementation of the "clocked" AAA technology at financial institution back 
office. Summarizing, it can be said that financial transaction authorization session processing 
time is not limited by financial institution back office "clocked" AAA technology, but rather by 
the entry data flow rate at a party at the point of sale locations. 

25 Authentication sessions in EPSL "clocked" AAA technology are not time limited and 

can not be replaced by an automated electronic interaction between financial account holder 
devices (for instance, smart cards or mobile phones) and financial institution back office. It is 
because they include an interactive communication sessions between financial account holders 
and the financial institution back office, which constitutes the third security protection tier. This 

30 is sort of a trade off between financial institution EPSL technology security protection and 
inconvenience in using this technique. Fortunately, authentication sessions in the EPSL 
technology are performed prior to financial transaction, and the financial account holder can 
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choose a time, when he / she is comfortable to get the transaction signature from financial 
institution back office. The way the financial account holder keeps the transaction signature after 
the authentication session is completed and before it is submitted to a party at the point of sale 
can vary. It can range from just writing it down into a notebook, to storing it electronically 
5 inside devices like smart cards, digital personal organizers with wireless connection capabilities 
and other electronic devices with read / write memory capabilities. 

Smart card technology is an excellent complement to make EPSL technology more 
comfortable for the financial account holder and the third party at the point of sale. Smart cards 
can be used as intermediate information carriers between the financial institution back office, 

10 which will write financial transaction signatures into smart cards during authentication sessions, 
and the financial account holder. Then it can be read out from smart cards at the point of sale 
locations to speed up authorization session requests. This way there are no issues with smart 
card security protection, since they can not be reused. Even if a smart card is lost or stolen 
before the current financial transaction signature was deactivated during an expected financial 

15 transaction at the point of sale location, nobody knows, what was (W/D)$ amount requested and 
how close this transaction signature is to its lifetime end. Moreover, even the fact that the card 
may still carry a signature is not apparent. Therefore, chances are high that even in this case 
fraudulent actions will be unsuccessful. More than that, a smart card may not contain financial 
institution EPSL account number (it could be residing on EPSL membership cards). In this case, 

20 smart cards have absolute security protection against fraudulent actions at any time. 

Mobil phones, network computers or other portable electronic devices having 
information read / write capabilities can be made as convenient as smart cards, functioning as 
intermediate authentication information carriers for one specific financial transaction (financial 
transaction alphanumeric signatures) between financial institution back office and a party at the 

25 point of sale. 

The last note relates to utilizing financial institution EPSL architecture with "clocked" 
AAA technology at ATM stations. A financial account holder can perform an authentication 
session for a withdraw financial transaction either before or right during operations at ATM 
stations. In any event, once the authentication session with financial institution back office is 
30 completed, the financial account holder operates at ATM station as at the point of sale location, 
provided ATM stations hardware and software are altered to perform authorization requests in 
the EPSL architecture. This makes money withdraw sessions at ATM stations highly secured 
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and protected against information to be looked after, stolen or fraudulently used, while 
preserving complete privacy of personal information. 

Finally, it should be emphasized that the described innovation can be used on and off 
line, and for private and non-private sessions, in all cases for a highly secure financial 
5 transaction. If a financial account holder is not concerned with financial transaction privacy, the 
financial account holder name can be placed on the card and become one more parameter 
utilized in the "clocked" AAA technology. Meanwhile, use of EPSL financial transaction 
architecture and the "clocked" AAA technology for non-private financial transactions provides 
improved (essentially, "bullet prove") security of on and offline financial transaction. The entire 
10 EPSL architecture and the "clocked" AAA at financial institution back office for non-private 
financial transactions can be viewed as the fourth security tier, whereas in a case of private 
financial transactions, it is still the fourth security layer and the main embedded privacy layer as 
well. 

Though the invention has been described in connection with preferred embodiments of 
15 the system and method for private and secure transactions, it is understood that the preferred 
embodiments have been used for the purpose of illustrating the manner in which the invention 
may be made and used. It should also be understood that implementation of other variations and 
modifications of the invention and its various aspects will be apparent to those skilled in the art, 
and that invention is not limited to these preferred embodiments described above. It is therefore 
20 contemplated to cover by present invention any and all modifications, variations, or equivalents 
that fall within true spirit and scope of the basic underlying principles disclosed hereinafter by 
the claims. 

I claim: 

25 
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CLAIMS 



1 1 . A method for managing financial transactions, comprising: 

2 performing an authentication process for a predicted transaction by a particular account 

3 holder, the predicted transaction having a predicted transaction amount and a predicted 

4 transaction time, the authentication process producing a transaction signature for presentation 

5 upon execution of the predicted transaction; 

6 performing an authorization process for a particular transaction having actual transaction 

7 amount and an actual transaction time upon presentation of the transaction signature, including 

8 verifying that the presented transaction signature matches the transaction signature for the 

9 predicted transaction, the actual transaction amount matches the predicted transaction amount 

10 and the actual transaction time matches the predicted transaction time; and 

1 1 performing an accounting process for the particular transaction as a result of a successful 

12 authorization process, including reconciling the predicted transaction amount and the actual 

13 transaction amount for the particular account holder. 

1 2. The method of claim 1, including: 

2 storing the predicted transaction amount and the transaction signature for a predicted 

3 transaction in a database. 

1 3. The method of claim 2, including storing a predicted transaction time in the 

2 database. 

1 4. The method of claim 1 , including setting up a time out interval between the 

2 authentication process and the authorization process. 

1 5. The method of claim 1, wherein the authentication process includes: 

2 establishing a communication session between the particular account holder and a 

3 financial transaction server; 

4 at the server, accepting an account number and an identification number for the particular 

5 account holder; 

6 at the server, accepting the predicted transaction amount; 
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7 at the server, producing the transaction signature and sending the transaction signature to 

8 the particular account holder; and 

9 entering identifying information for the predicted transaction in a memory at the server. 

1 6. The method of claim 5, wherein the authentication process includes prompting 

2 the particular account holder to supply a combination of digits from a personal identification 

3 code, wherein the combination does not include all of the personal identification code. 

1 7. The method of claim 1, wherein the authorization process includes: 

2 establishing a communication session between a party to the particular transaction and a 

3 financial transaction server; 

4 at the server, accepting the presented transaction signature and the actual transaction 

5 amount; 

6 at the server, comparing a time of the particular transaction with the predicted time, and 

7 comparing the presented transaction signature and actual transaction amount with the predicted 

8 transaction amount associated with the transaction signature for the predicted transaction; and 

9 at the server, sending an authorization message to the party. 

1 8. The method of claim 7, including accepting identification of the party at the 

2 server. 

1 9. The method of claim 7, wherein the authorization process operates without 

2 identification of the particular account holder to the party. 

1 1 0. The method of claim 7, wherein the authorization process operates with 

2 identification of the particular account holder to the party. 

1 11. The method of claim 1 , wherein the authentication process includes routines: 

2 establishing a communication session between the particular account holder and a 

3 financial transaction server; 

4 accepting an account number as input; 
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5 prompting the particular account holder to supply a static identification number and a 

6 dynamically identified combination of digits from a personal identification code, wherein the 

7 combination does not include all of the personal identification code; 

8 accepting the predicted transaction amount as input; 

9 producing the transaction signature and sending the transaction signature to the particular 

10 account holder; and 

1 1 entering identifying information for the predicted transaction in a memory. 

1 12. A method for managing financial transactions, comprising: 

2 executing an authentication process over communication media for a predicted 

3 transaction by a particular account holder, including receiving a predicted transaction amount at 

4 an authentication time, the authentication process producing a transaction signature for 

5 presentation upon execution of the predicted transaction, communicating the transaction 

6 signature to the particular account holder, and storing the transaction signature and parameters 

7 associated with the particular transaction; 

8 executing an authorization process over communication media for a particular 

9 transaction having actual transaction amount and an actual transaction time, including receiving 

10 the transaction signature over communication media from a party to the particular transaction at 

1 1 an authorization time, verifying that the received transaction signature matches the transaction 

12 signature stored for the predicted transaction, the actual transaction amount matches the 

13 predicted transaction amount and the authorization time meets a time criterion; and 

14 executing an accounting process for the particular transaction as a result of a successful 

15 authorization process, including reconciling the predicted transaction amount and the actual 

16 transaction amount for the particular account holder. 

1 13. The method of claim 12, including: 

2 storing the transaction signature and the parameters associated with the predicted 

3 transaction in a database. 

1 14. The method of claim 13, including storing a parameter indicating acceptable 

2 transaction times in the database. 
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1 15. The method of claim 1 2, including setting up a time out interval between the 

2 authentication time and the authorization time. 

1 1 6. The method of claim 1 2, wherein the authentication process includes: 

2 establishing a private communication session between the particular account holder and a 

3 financial transaction server; 

4 at the server, accepting an account number and an identification number for the particular 

5 account holder; 

6 at the server, accepting the predicted transaction amount; 

7 at the server, producing the transaction signature and sending the transaction signature to 

8 the particular account holder; and 

9 entering identifying information for the predicted transaction in a memory at the server. 

1 1 7. The method of claim 1 6, wherein the authentication process includes prompting 

2 the particular account holder to supply a combination of digits from a personal identification 

3 code, wherein the combination does not include all of the personal identification code. 

1 1 8. The method of claim 12, wherein the authorization process includes: 

2 establishing a private communication session between a party to the particular 

3 transaction and a financial transaction server; 

4 at the server, accepting the presented transaction signature and the actual transaction 

5 amount; 

6 at the server, determining whether the authorization time falls within an acceptable time 

7 window, and comparing the presented transaction signature and actual transaction amount with 

8 the predicted transaction amount associated with the transaction signature for the predicted 

9 transaction; and 

10 at the server, sending an authorization message to the party. 

1 1 9. The method of claim 18, including accepting identification of the party at the 

2 server. 
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1 20. The method of claim 1 8, wherein the authorization process operates without 

2 identification of the particular account holder to the party. 

1 21. The method of claim 1 8, wherein the authorization process operates with 

2 identification of the particular account holder to the party. 

1 22. The method of claim 12, wherein the authentication process includes: 

2 establishing a communication session between the particular account holder and a 

3 financial transaction server; 

4 accepting an account number as input; 

5 prompting the particular account holder to supply a static identification number and a 

6 dynamically identified combination of digits from a personal identification code, wherein the 

7 combination does not include all of the personal identification code; 

8 accepting the predicted transaction amount as input; 

9 producing the transaction signature and sending the transaction signature to the particular 

10 account holder; and 

1 1 entering identifying information for the predicted transaction in a memory. 

12 23. A financial transaction server, comprising: 

13 a communication interface; 

14 a data processing system coupled to the communication interface, the data processing 

15 system including resources for managing financial transactions, including 

16 an authentication process communicating over the communication interface for 

17 authenticating predicted transaction by a particular account holder, including routines which 

18 handle receiving a predicted transaction amount at an authentication time, producing a 

19 transaction signature for presentation upon execution of the predicted transaction, 

20 communicating the transaction signature to the particular account holder, and storing the 

21 transaction signature and parameters associated with the particular transaction; 

22 an authorization process communicating over the communication interface for 

23 authorizing a particular transaction having actual transaction amount and an actual transaction 

24 time, including routines for handling receiving the transaction signature over the communication 
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25 interface from a party to the particular transaction at an authorization time, verifying that the 

26 received transaction signature matches the transaction signature stored for the predicted 

27 transaction, that the actual transaction amount matches the predicted transaction amount and that 

28 the authorization time meets a time criterion; and 

29 an accounting process executed for the particular transaction as a result of a successful 

30 authorization process, including routines reconciling the predicted transaction amount and the 

3 1 actual transaction amount for the particular account holder. 

1 24. The financial transaction server of claim 23, wherein the data processing system 

2 includes a local or remote database storing the transaction signature and the parameters 

3 associated with the predicted transaction. 

1 25. The financial transaction server of claim 24, including a parameter indicating 

2 acceptable transaction times stored in the database. 

1 26. The financial transaction server of claim 23, wherein the data processing system 

2 includes a routine setting up a time out interval between the authentication time and the 

3 authorization time. 

1 27. The financial transaction server of claim 23, wherein the authentication process 

2 includes routines: 

3 establishing a private communication session between the particular account holder and a 

4 financial transaction server; 

5 accepting an account number and an identification number for the particular account 

6 holder; 

7 accepting the predicted transaction amount; 

8 producing the transaction signature and sending the transaction signature to the particular 

9 account holder; and 

10 entering identifying information for the predicted transaction in a memory. 

1 28. The financial transaction server of claim 27, wherein the authentication process 

2 includes a routine prompting the particular account holder to supply a combination of digits 
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3 from a personal identification code, wherein the combination does not include all of the personal 

4 identification code. 

1 29. The financial transaction server of claim 23, wherein the authorization process 

2 includes routines: 

3 establishing a private communication session between a party to the particular 

4 transaction and a financial transaction server; 

5 accepting the presented transaction signature and the actual transaction amount; 

6 determining whether the authorization time falls within an acceptable time window, and 

7 comparing the presented transaction signature and actual transaction amount with the predicted 

8 transaction amount associated with the transaction signature for the predicted transaction; and 

9 sending an authorization message to the party. 

1 30. The financial transaction server of claim 29, wherein the authorization process 

2 includes a routine accepting identification of the party at the server. 

1 31. The financial transaction server of claim 29, wherein the authorization process 

2 operates without identification of the particular account holder to the party. 

1 32. The financial transaction server of claim 29, wherein the authorization process 

2 operates with identification of the particular account holder to the party. 

1 33. The financial transaction server of claim 23, wherein the authentication process 

2 includes routines: 

3 establishing a communication session between the particular account holder and a 

4 financial transaction server; 

5 accepting an account number as input; 

6 prompting the particular account holder to supply a static identification number and a 

7 dynamically identified combination of digits from a personal identification code, wherein the 

8 combination does not include all of the personal identification code; 

9 accepting the predicted transaction amount as input; 
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10 producing the transaction signature and sending the transaction signature to the particular 

1 1 account holder; and 

12 entering identifying information for the predicted transaction in a memory. 

13 34. A article of manufacture, comprising: 

14 a machine readable storage medium; 

15 a computer program stored on said machine readable medium with resources for 

16 managing financial transactions, including 

17 an authentication process communicating over the communication interface for 

1 8 authenticating predicted transaction by a particular account holder, including 

19 routines which handle receiving a predicted transaction amount at an 

20 authentication time, producing a transaction signature for presentation upon 

21 execution of the predicted transaction, communicating the transaction signature to 

22 the particular account holder, and storing the transaction signature and parameters 

23 associated with the particular transaction; 

24 an authorization process communicating over the communication interface for 

25 authorizing a particular transaction having actual transaction amount and an 

26 actual transaction time, including routines for handling receiving the transaction 

27 signature over the communication interface from a party to the particular 

28 transaction at an authorization time, verifying that the received transaction 

29 signature matches the transaction signature stored for the predicted transaction, 

30 that the actual transaction amount matches the predicted transaction amount and 

3 1 that the authorization time meets a time criterion; and 

32 an accounting process executed for the particular transaction as a result of a successful 

33 authorization process, including routines reconciling the predicted transaction 

34 amount and the actual transaction amount for the particular account holder. 

1 35. The article of claim 34, wherein the resources include a routine for storing the 

2 transaction signature and the parameters associated with the predicted transaction in a local or 

3 remote database. 
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1 36. The article of claim 35, including the parameters included parameter indicating 

2 acceptable transaction times stored in the database. 

1 37. The article of claim 34, wherein the resources include a routine setting up a time 

2 out interval between the authentication time and the authorization time. 

1 38. The article of claim 34, wherein the authentication process includes routines: 

2 establishing a communication session between the particular account holder and a 

3 financial transaction server; 

4 accepting an account number and an identification number for the particular account 

5 holder; 

6 accepting the predicted transaction amount; 

7 producing the transaction signature and sending the transaction signature to the particular 

8 account holder; and 

9 entering identifying information for the predicted transaction in a memory. 

1 39. The article of claim 38, wherein the authentication process includes a routine 

2 prompting the particular account holder to supply a combination of digits from a personal 

3 identification code, wherein the combination does not include all of the personal identification 

4 code. 

1 40. The article of claim 34, wherein the authorization process includes routines: 

2 establishing a private communication session between a party to the particular 

3 transaction and a financial transaction server; 

4 accepting the presented transaction signature and the actual transaction amount; 

5 determining whether the authorization time falls within an acceptable time window, and 

6 comparing the presented transaction signature and actual transaction amount with the predicted 

7 transaction amount associated with the transaction signature for the predicted transaction; and 

8 sending an authorization message to the party. 

1 41 . The article of claim 40, wherein the authorization process includes a routine 

2 accepting identification of the party at the server. 
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1 42. The article of claim 40, wherein the authorization process operates without 

2 identification of the particular account holder to the party. 

1 43 . The article of claim 40, wherein the authorization process operates with 

2 identification of the particular account holder to the party. 

1 44. The article of claim 34, wherein the authentication process includes routines: 

2 establishing a communication session between the particular account holder and a 

3 financial transaction server; 

4 accepting an account number; 

5 prompting the particular account holder to supply a static identification number and a 

6 dynamically identified combination of digits from a personal identification code, wherein the 

7 combination does not include all of the personal identification code; 

8 accepting the predicted transaction amount; 

9 producing the transaction signature and sending the transaction signature to the particular 

10 account holder; and 

1 1 entering identifying information for the predicted transaction in a memory. 

1 45. A method for automated authentication, authorization and accounting for 

2 financial transactions, comprising: 

3 establishing an authentication record for a predicted transaction by a particular account 

4 holder, the predicted transaction having a predicted transaction amount and a transaction time 

5 parameter, and an authenticated transaction signature for presentation upon execution of the 

6 predicted transaction; 

7 establishing an authorization record for a particular transaction indicating an actual 

8 transaction amount, an actual transaction time and a presented transaction signature; 

9 matching the authorization record with the authentication record to determine whether 

10 the presented transaction signature matches the authenticated transaction signature for the 

1 1 predicted transaction, the actual transaction amount matches the predicted transaction amount 

12 and the actual transaction time matches the transaction time parameter; and 
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13 reconciling the predicted transaction amount and the actual transaction amount for the 

14 particular account holder. 

1 46. The method of claim 45, including: 

2 storing the authentication record in a database including a plurality of authentication 

3 records for other predicted transactions. 

1 47. The method of claim 45, wherein the time parameter comprises a time value 

2 indicated when the authorization record was created. 

1 48. The method of claim 45, wherein said matching includes determining whether the 

2 actual transaction time falls within a time interval indicated by the transaction time parameter. 

1 49. The method of claim 45, wherein establishing an authentication record includes: 

2 establishing a communication session between the particular account holder and a 

3 financial transaction server; 

4 at the server, accepting an account number and an identification number for the particular 

5 account holder; 

6 at the server, accepting the predicted transaction amount; 

7 at the server, producing the transaction signature. 

1 50. The method of claim 49, including prompting the particular account holder to 

2 supply a combination of digits from a personal identification code, wherein the combination 

3 does not include all of the personal identification code. 

1 51 . The method of claim 45, wherein establishing an authorization record includes: 

2 establishing a communication session between a party to the particular transaction and a 

3 financial transaction server; 

4 at the server, accepting the presented transaction signature and the actual transaction 

5 amount. 
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1 52. The method of claim 5 1 , including accepting identification of the party at the 

2 server. 

1 53. The method of claim 52, including maintaining a list of authorized parties, and 

2 wherein said matching includes determining whether the identification of the party indicates a 

3 party in the list of authorized parties. 

1 54. The method of claim 5 1 , wherein said establishing an authorization record does 

2 not require identification of the particular account holder. 

1 55. The method of claim 45, wherein establishing an authentication record includes: 

2 establishing a communication session between the particular account holder and a 

3 financial transaction server; 

4 accepting an account number; 

5 prompting the particular account holder to supply a static identification number and a 

6 dynamically identified combination of digits from a personal identification code, wherein the 

7 combination does not include all of the personal identification code; 

8 accepting the predicted transaction amount; 

9 producing the transaction signature and sending the transaction signature to the particular 
10 account holder. 
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SYSTEM AND METHOD FOR PRIVATE AND SECURE 
FINANCIAL TRANSACTIONS 

ABSTRACT 

A system and method for private and secure financial transactions. The system and 
method comprise embedded into financial institutions (financial institution ) privacy and 
security layer architecture and the "clocked" authentication, authorization and accounting 
5 (AAA) method. The system and method enable legal financial account holders (financial 
account holder) to perform buy/sell or withdraw/deposit financial transactions (financial 
transaction ) without disclosing private personal information to the transaction counterparts, 
while preserving highly elevated and enhanced security and fraud protection as compared with 
conventional methods. Before financial transaction , financial account holder initiates an 

10 authentication session with financial institution back office (financial institution back office) by 
accessing its central processing unit (CPU) and data base (dB), configured in the embedded 
privacy and security layer (EPSL) architecture with automated "clocked" AAA sessions by 
using dedicated communication lines. The authentication session is interactive, transaction 
specific and followed by either financial transaction deny or an alphanumeric signature 

15 generated for this specific financial transaction . Then financial account holder submits his/her 
request to a transaction counterpart along with the EPSL account number and the alphanumeric 
signature, generated by financial institution EPSL during previous authentication session. The 
transaction counterpart adds up additional or more refined financial transaction specific 
information and requests an authorization session with financial institution back office where the 

20 EPSL account, CPU and dB are residing. The accounting session starts at the end of the 

authentication session and finishes along with the authorization session while being an essential 
part of them both. The system and method are particularly suited for use by banks, credit card 
companies and brokerage companies. Finally, the system and method are well adapted to the 
current and upcoming software, hardware, and electronic commerce technologies and can be 

25 easily implemented given an acceptable business trade off. 
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LEGAL ADULT 
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appointment to be to the exclusion of the inventors and the inventors' attorneys in accordance 
with the provisions of 37 C.F.R. § 3.71. 

The following evidentiary documents establish a chain of title from the original owner to 
the Assignee: 

X a copy of an Assignment attached hereto, which Assignment has been (or is herewith) 
forwarded to the Patent and Trademark Office for recording; or 

the Assignment recorded on at reel , frames . 
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Pursuant to 37 C.F.R. § 3.73(b) the undersigned Assignee hereby states that evidentiary 
documents have been reviewed and hereby certifies that, to the best of ASSIGNEE'S 
knowledge and belief, title is in the identified ASSIGNEE. 



Direct all telephone calls to Mark A. Haynes, Esq., at (650) 712-0340. 

Address all correspondence to: 

Customer Number 22470 

Mark A. Haynes, Esq. 
HAYNES & BEFFEL LLP 
P.O. Box 366 

Half Moon Bay, CA 94019 
(650) 712-0340 (phone) 
(650) 712-0263 (fax) 



ASSIGNEE: AID TECHNOLOGIES, INC. 
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Name: Len L . Mizrah 

Title: VP of Engineering 
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SOLE TO CORPORATE 
ASSIGNMENT 



WHEREAS, the undersigned, 



(1) LenL. Mizrah 
157 Glasgow Lane 
San Carlos, CA 94070 



hereinafter termed "Inventor", has invented certain new and useful improvements in 

SYSTEM AND METHOD FOR PRIVATE AND SECURE FINANCIAL 
TRANSACTIONS 

and has filed an application for a United States patent disclosing and identifying the above invention on 

as Application No. , OR are filing such an application herewith, and have executed 

an oath or declaration of inventorship for such application on: 

(1) th e 2nd dav g f vemt ? 35<)0: 



(hereinafter termed "application"); and 

WHEREAS, AID Technologies. Inc. . a corporation of California , having a place of business at 
1 958 Stratton Circle. Walnut Creek. CA 94598 (hereinafter termed "Assignee"), is desirous of acquiring the 
entire right, title and interest in and to said application and the invention disclosed therein, and in and to all 
embodiments of the invention, heretofore conceived, made or discovered jointly or severally by said 
Inventors (all collectively hereinafter termed "said invention"), and in and to any and all patents, inventor's 
certificates and other forms of protection (hereinafter termed "patents") thereon granted in the United States 
and foreign countries. 

NOW, THEREFORE, in consideration of good and valuable consideration acknowledged by said 
Inventor to have been received in full from said Assignee: 

1. Said Inventor does hereby sell, assign, transfer and convey unto said Assignee the entire 
right, title and interest (a) in and to said application and said invention; (b) in and to all rights to apply for 
foreign patents on said invention pursuant to the International Convention for the Protection of Industrial 
Property or otherwise; (c) in and to any and all applications filed and any and all patents granted on said 
invention in the United States or any foreign country, including each and every application filed and each 
and every patent granted on any application which is a divisional, substitution, continuation, or continuation- 
in-part of any of said applications; and (d) in and to each and every reissue or extensions of any of said 
patents. 

2. Said Inventor hereby jointly and severally covenants and agrees to cooperate with said 
Assignee to enable said Assignee to enjoy to the fullest extent the right, title and interest herein conveyed 
in the United States and foreign countries. Such cooperation by said Inventor shall include prompt 
production of pertinent facts and documents, giving of testimony, execution of petitions, oaths, 
specifications, declarations or other papers, and other assistance all to the extent deemed necessary or 
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desirable by said Assignee (a) for perfecting in said Assignee the right, title and interest herein conveyed; 
(b) for prosecuting any of said applications; (c) for filing and prosecuting substitute, divisional, continuing 
or additional applications covering said invention; (d) for filing and prosecuting applications for reissuance 
of any said patents; (e) for interference or other priority proceedings involving said invention; and (f) for 
legal proceedings involving said invention and any applications therefor and any patents granted thereon, 
including without limitation reissues and reexaminations, opposition proceedings, cancellation proceedings, 
priority contests, public use proceedings, infringement actions and court actions; provided, however, that the 
expense incurred by said Inventor in providing such cooperation shall be paid for by said Assignee. 

3. The terms and covenants of this assignment shall inure to the benefit of said Assignee, its 
successors, assigns and other legal representatives, and shall be binding upon said Inventor, his respective 
heirs, legal representatives and assigns. 

4. Said Inventor hereby jointly and severally warrants and represents that they have not entered 
and will not enter into any assignment, contract, or understanding in conflict herewith. 

IN WITNESS WHEREOF, said Inventor has executed and delivered this instrument to said 
Assignee as of the dates written below. 




County of 



State of 



) 
) 
) 



Len L. Mizrah 



On , 2000, before me, 



personally appeared . 



Date 



11-02-00 



personally known to me or I I proved to me on the basis of 

satisfactory evidence, to be the person whose name is subscribed 
to the within instrument and acknowledged to me that he/she 
executed the same in his/her authorized capacity, and that by 
his/her signature on the instrument the person or the entity upon 
behalf of which the person acted, executed the instrument. 



WITNESS my hand and official seal. 



(Notary Public) 
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COMBINED DECLARATION AND POWER OF ATTORNEY 
FOR UTILITY PATENT APPLICATION 

As a below-named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my name; 

I believe I am the original, first and sole inventor (if only one name is listed below) or an 
original, first and joint inventor (if plural names are listed below) of the subject matter which is claimed 
and for which a patent is sought on the invention entitled: 

SYSTEM AND METHOD FOR PRIVATE AND SECURE FINANCIAL 
TRANSACTIONS 

the specification of which 

XX is attached hereto. 

was filed on as Application No. 

and was amended on . 

(if applicable) 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information which is material to the examination of this 
application in accordance with Title 37, Code of Federal Regulations, § 1.56(a) which states in relevant 
part: "Each individual associated with the filing and prosecution of a patent application has a duty of 
candor and good faith in dealing with the Office, which includes a duty to disclose to the Office all 
information known to that individual to be material to patentability as defined in this section.... The duty 
to disclose all information known to be material to patentability is deemed to be satisfied if all 
information known to be material to patentability of any claim issued in a patent was cited by the Office 
or submitted to the Office in the manner prescribed by §§ 1.97(b)-(d) and 1.98." 

I hereby claim foreign priority benefits under Title 35, United States Code, § 1 19 of any foreign 
application(s) for patent or inventor's certificate as indicated below and have also identified below any 
foreign application for patent or inventor's certificate on this invention having a filing date before that 
of the application on which priority is claimed: 

Prior Foreign Application(s) Priority Claimed 



(Number) (Country) (Day/Month/Year Filed) Yes No 



(Number) (Country) (Day/Month/Year Filed) Yes No 
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I hereby claim the benefit under Title 35, United States Code, §120 of any United States 
application(s), and under § 119(e) of any United States provisional application(s), listed below and, 
insofar as the subject matter of each of the claims of this application is not disclosed in the prior United 
States application in the manner provided by the first paragraph of Title 35, United States Code, §112, 
I acknowledge the duty to disclose material information as defined in Title 37, Code of Federal 
Regulation, § 1 .56(a) which occurred between the filing date of the prior application and the national or 
PCT international filing date of this application: 



(Application Serial No.) (Filing Date) (Patented, Pending, Abandoned) 



(Application Serial No.) (Filing Date) (Patented, Pending, Abandoned) 

I hereby appoint the following attorney(s) and/or agent(s) to prosecute this application and transact 
all business in the Patent and Trademark Office connected therewith, and to file, prosecute and to 
transact all business in connection with international applications directed to said invention: 

Mark A. Haynes - Reg. No. 30,846 
Ernest J. Beffel, Jr. - Reg. No. 43,489 

Address all correspondence to: 

CUSTOMER NO. 22470 

Mark A. Haynes 
Haynes & Beffel LLP 
P.O. Box 366 

Half Moon Bay, CA 94019 

Direct all telephone calls to Mark A. Havnes at (650) 712-0340. 

I hereby declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these statements were 
made with the knowledge that willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Title 1 8, United States Code, § 1001 and that such willful false statements 
may jeopardize the validity of the application or any patent issued thereon. 

Full name of first joint 
inventor, if any: 

Inventor's signature: 

Date: 

Citizenship: 
Residence: 



Post Office Address: 
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United States 



157 Glasgow Lane 



San Carlos. CA 94070 
Same as above. 



